Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-154 < prev next >

Wrap

Text File | 1988-12-01 | 23.9 KB | 766 lines

INDRA Working Paper INDRA Note 965 TSIG 4.1 IEN 154 7th August 1980 Realization of the Yellow Book Transport Service Above TCP C. J. Bennett ABSTRACT: This note defines an enhancement of the service provided by the US DoD Standard Transmission Control Protocol (TCP) sufficient to meet the requirements of the UK Network Independent Transport Service (the Yellow Book). This note supersedes an earlier version (INDRA Note 959, TSIG 4.0 and IEN 153). Department of Computer Science University College London 1. Introduction This document defines a means of providing the Yellow Book Transport Service [1] above the DARPA Internet facilities, in particular TCP [2], so that this can then be used to support other services such as endpoint file transfer without requiring UK hosts to implement the Internet family of protocols. It assumes familiarity with both TCP and the Yellow Book. The basic approach taken is to enhance the TCP service along the lines suggested for enhancing X25 in Annex I of the Yellow Book, taking into account the different services provided by TCP. In addition, the note discusses how to integrate Yellow Book TCP so that it can run alongside ordinary TCP - an issue the Yellow Book ignores for Yellow Book X25. 2. Deficiencies of TCP A comparison of the services provided by TCP and those provided by the Yellow Book reveals that TCP is unable to support directly, either in whole or in part, the following Yellow Book features: (i) The RESET and ADDRESS primitives. (ii) The Yellow Book multiple-domain addressing structure. The TCP address space constitutes a single naming domain in Yellow Book terms. Consequently, features involving addressing - notably ACCEPT - are inadequately supported by TCP. (iii) Much of the subsidiary information provided with Yellow Book primitives. The fact that the source address provided with certain actions such as DISCONNECT is not provided is again a limitation of the global TCP naming domain. The Yellow Book 'Explanatory Text' parameters have no corresponding feature in TCP. (iv) The closest equivalent to Yellow Book EXPEDITED data - theoretically requiring a priority data channel - is TCP URGENT data. However, TCP URGENT data remains in sequence, and the URGENT pointer only marks the end of the data. Its beginning is not delimited. (v) The Yellow Book DISCONNECT is a full-duplex close, whereas the TCP CLOSE is only half- duplex. The TCP RESET is a unilateral close, used in error conditions. Connection closure Bennett 1 INDRA 965 Yellow Book above TCP provides particularly subtle problems. Hence in order to provide a Yellow Book service above TCP an enhancement of TCP is necessary. The remainder of this document discusses such an enhancement. 3. Principles of the Enhancement The basic principles of the enhancement are as follows: (i) Where a TCP function corresponds directly to a Yellow Book function that TCP function is used directly. (ii) Where the Yellow Book function requires more information or action, the TCP function is associated with a TCP Control Message in a defined way. This message is a record of defined format containing the information required. (iii) Where there is no TCP function even remotely corresponding to the required Yellow Book function, a control message is defined which may be used by the source and destination processes if possible, and may be forwarded into other transport domains more capable of taking the appropriate action. 4. The Yellow Book TCP Enhancement 4.1 Distinguishing the Yellow Book TCP The services using the Yellow Book enhancement to the TCP will be identifiable through the TCP socket number used. These will be allocated for standard services as required. 4.2 Identification of Yellow Book TCP Messages The data stream is structured into records, which in turn are substructured depending on the record type. These records are independent of TCP letter indications as the latter are purely push delimiters. Bennett 2 INDRA 965 Yellow Book above TCP The record structure proposed is as illustrated in Figure 1. Each record is prefaced by a single octet, known as the TYPE octet. This takes a value of 0 for data records and a value of 1 for command messages. All other values are undefined. +------+----- - - - - - ------+ | TYPE | RECORD BODY | +------+----- - - - - - ------+ | | / | | 0 = DATA |-------< | 1 = COMMAND \ Figure 1: Letter Structure in Yellow Book TCP 4.3 Structure of TCP Data Messages A TCP Data Message is a Yellow Book TCP record of TYPE 0. Each record consists of a number of SUBRECORDS. Each subrecord consists of a header octet and a number of data octets, up to a limit of 127 octets. The subrecord header is a single octet. The high- order bit of this octet, if set to 1, declares that the current subrecord is the last subrecord of the current record. The remaining seven bits define the length in octets of the current record. Bennett 3 INDRA 965 Yellow Book above TCP This structure is illustrated in Figure 2. +-------- - - - - - - - - --------+ | DATA MESSAGE | +-------- - - - - - - - - --------+ / \ / \ / \ / \ +-------- - - + - - - - - - - + - - --------+ | SUBRECORD 1 | ........... | SUBRECORD K | Data Record +-------- - - + - - - - - - - + - - --------+ Structure | \ | \ | \ | \ +--------+------ - - - - - -------+ | HEADER | BODY | Subrecord Structure +--------+------ - - - - - -------+ | \ | \ | \ +-+-+-+-+-+-+-+-+ | | C O U N T | Header Structure +-+-+-+-+-+-+-+-+ | |--- EOR Bit Figure 2: TCP Data Message Structure 4.4 Structure of TCP Command Messages A TCP Command Message is a Yellow Book TCP record of TYPE 1. The first octet of the message defines the COMMAND CODE of the message. These codes are defined in subsequent sections, and have been chosen to correspond to the command codes of the X25 Command Messages. Following the command code is a number of PARAMETERS. The significance of these parameters is defined by their position in the parameter sequence for each command, and the command message is completed only when all parameters have been specified; thus no parameter may be omitted, though it may have a null value. Bennett 4 INDRA 965 Yellow Book above TCP Most parameters have a free field format. For this reason each parameter is constructed of a number of FRAGMENTS. These fragments consist of a header byte and the body of the fragment, which may have a maximum length of 127 octets. The fragment header is a single octet. The high-order bit of this octet, if set to 1, declares that the current fragment is the last fragment of the current parameter. The remaining seven bits define the length in octets of the current fragment. This structure is summarised in Figure 3. +-------- - - - - - - - - --------+ | COMMAND MESSAGE | +-------- - - - - - - - - --------+ / \ / \ / \ +------+-------- - - + - - - - - + - - -------+ | CODE | PARAM 1 | ....... | PARAM N | Command +------+-------- - - + - - - - - + - - -------+ Structure / \ / \ / \ / \ +-------- - - + - - - - - + - - --------+ | FRAG 1 | ....... | FRAG K | Parameter +-------- - - + - - - - - + - - --------+ Structure | \ | \ | \ | \ +--------+------ - - - - - -------+ | HEADER | BODY | Fragment Structure +--------+------ - - - - - -------+ | \ | \ | \ +-+-+-+-+-+-+-+-+ | | C O U N T | Header Structure +-+-+-+-+-+-+-+-+ | |--- EOP Bit Figure 2: TCP Command Message Structure Bennett 5 INDRA 965 Yellow Book above TCP A parameter with a null value is represented by a fragment header whose EOP bit is set to 1 and whose count field is set to 0. The rules governing the syntax of free-field parameters are the same as those defined in section 2.7 of the Yellow Book, based on the use of the IA5 character set, except where otherwise noted. The sole difference between this structure and the X25 Command Message structure is that the count field in the fragment header is extended by one bit - this bit is used for a specific purpose in X25 CONNECT messages which does not arise with the TCP. This doubles the maximum fragment size. Because of the similarity of structure the same terminology has been used, though the term 'fragment' is somewhat unfortunate in the DARPA context through its specific association with the Internet Datagram Protocol. 4.5 Yellow Book Commands and TCP The following general remarks apply to the following specification: (i) All codes are specified as decimal integers. (ii) All address fields include the appropriate TCP address components, specified as /<NET ID>+<INTERNET HOST ID>+<PORT NO>/, where the bracketed fields are the character strings of the octal representations of those TCP fields. Where a field consists of more than 8 bits, it is further subdivided into eight bit units separated by commas for representational purposes. Thus, the NIFTP port (octal 10651) at ISIE (net 12, host 1, logical host 0, IMP 64) will be denoted by the string: /12+1,0,64+21,251/ (iii) All command messages must be accompanied by a TCP end of letter at the end of the last fragment of the last parameter. 4.5.1 CONNECT The CONNECT command message is defined by the following code and parameters: Bennett 6 INDRA 965 Yellow Book above TCP Code = 16 Parameter 1: Called Address Parameter 2: Calling Address Parameter 3: Quality of Service Parameter 4: Explanatory Text This message will be preceded by the usual TCP three-way handshake. Where possible or appropriate, the quality of service parameter will be used to select TCP quality of service from the options defined in the TCP specification. The CONNECT message will be the first message sent by the calling party. It will be possible for the calling party to initiate the transfer of data before the arrival of an ACCEPT message. 4.5.2 ACCEPT The ACCEPT command message is defined by the following code and parameters: Code = 17 Parameter 1: Recall Address Parameter 2: Quality of Service Parameter 3: Explanatory Text This message will be the first message sent by the called party after the three-way handshake, unless the call request was rejected (see DISCONNECT, below). 4.5.3 DISCONNECT The DISCONNECT command message is defined by the following code and parameters: Code = 18 Parameter 1: Reason Parameter 2: Address of DISCONNECT Initiator Parameter 3: Explanatory Text The reason parameter is a single octet giving a machine-oriented encoding of the reason the DISCONNECT was initiated. The defined reasons are listed in Appendix B of the body of the Yellow Book. Parameter 2 is included to cover the case where the DISCONNECT was initiated by some intermediate gateway (where 'gateway' is used in the Yellow Book sense). Bennett 7 INDRA 965 Yellow Book above TCP DISCONNECT will always cause the TCP to issue an URGENT call. On receipt of a DISCONNECT message, no further data may be sent and all data currently queued for transmission should be flushed if possible. No data will be passed across to the user after a DISCONNECT has been issued. Beyond this, the exact DISCONNECT sequence used varies depending on the state of the connection, as follows: (i) If the DISCONNECT is being used to reject a CONNECT request, the DISCONNECT message will be followed by a TCP RESET. This will abort the TCP connection, flushing all outstanding data. No response is expected. The URGENT pointer points to the TCP RESET. (ii) In the normal case of closing an open connection, the DISCONNECT issued by the initiator will be followed by a TCP FIN. The remote party will respond with an optional DISCONNECT message accompanied by a FINACK and a FIN. The URGENT pointer points to the TCP FIN. (iii) For error terminations, a DISCONNECT message should be answered with a TCP RESET. The issuer of the DISCONNECT will also issue a TCP RESET after a timeout period, if a RESET has not already been received. The URGENT pointer points to the end of the DISCONNECT message. 4.5.4 DATA DATA is sent as a sequence of Yellow Book TCP data messages, as defined above. 4.5.5 PUSH The PUSH function is conveyed by use of the TCP EOL function, pointing to the data octet at which the PUSH was issued. Note that it is possible to collapse EOL indications, effectively combining PUSHes. Strictly speaking, the Yellow Book requires that a PUSH remains in sequence, but this is not necessary to obtain the required Bennett 8 INDRA 965 Yellow Book above TCP effect. In order to propagate the PUSH, it is necessary that the TCP delivers EOL indications to the user process. The circumstances under which this occurs are currently unclear. It may be necessary in the future to define a PUSH command message. 4.5.6 EXPEDITED The EXPEDITED command message is defined by the following code and parameter: Code = 21 Parameter 1: EXPEDITED data EXPEDITED data is accompanied by a TCP URGENT pointer pointing to the end of the message. There are no restrictions on the encoding of EXPEDITED data messages beyond the normal fragment structuring rules. It should be noted that this will cause the receiver of the URGENT to process all data up to the URGENT pointer in 'fast' mode, whether EXPEDITED or not. It may or may not be possible to deliver the EXPEDITED data to the user ahead of sequence. As noted above, TCP has no direct equivalent of a priority data channel, but the mechanism described at least allows the preservation of EXPEDITED data so that it may be passed as such in subsequent networks. 4.5.7 RESET The RESET command message is defined by the following code and parameters: Code = 19 Parameter 1: Reason Parameter 2: Address of RESET Initiator Parameter 3: Explanatory Text TCP has no equivalent of the RESET function (a TCP RESET is something else entirely). Thus the only TCP action taken with a RESET message is to accompany it with an URGENT pointer pointing to the end of the RESET message. As with DISCONNECT, the defined RESET reasons are those listed in Appendix B of the main portion of the Yellow Book. The address parameter is again included to cater for the case where a RESET was initiated in some Bennett 9 INDRA 965 Yellow Book above TCP intermediate network. A RESET may only be issued if the connection is fully open and there are no RESETs already outstanding. A RESET message must always be replied to with another RESET message, leaving the connection open, or with an error DISCONNECT message followed by a TCP RESET, which will abort the connection. All data and control messages, with the exception of DISCONNECT, received after a RESET has been issued and before a RESET reply has been received, will be discarded without informing the user. In the case of DISCONNECT, the connection will be considered as having closed in an abnormal state. If a DISCONNECT has been issued, a received RESET will be ignored. Where possible the issue of a RESET should cause the sender to flush its transmission buffers. 4.5.8 ADDRESS The ADDRESS command message is defined by the following code and parameters: Code = 20 Parameter 1: Address Parameter 2: Address Qualifier The ADDRESS qualifier is a single octet parameter taking one of the values defined in the Yellow Book: 0: The message is passing towards the addressed object. 1: The message is passing away from the addressed object. 2: An addressing error has been detected. There is no associated TCP action taken with an ADDRESS message. The receiver of an ADDRESS message will perform the appropriate ADDRESS transformation as defined in the Yellow Book. It is recommended that the ADDRESS function should not be used. Bennett 10 INDRA 965 Yellow Book above TCP 5. Conclusions One of the difficulties of writing a note such as this is that it is addressed to several audiences with different interests and not necessarily a great deal of overlap either in aim or in background. The immediate audience is the team at University College London who are involved in implementing a 'Protocol Convertor' to make possible direct access between hosts in Britain using the CCITT and UK national standards and the hosts in the US based on the DARPA Internet standards. For this audience, the document hopefully defines an answer to what will soon be a practical need, though it is a matter for continuing debate to what extent the full enhancement defined here will be implemented. Within Britain, the wider audience aimed at is centred on the Transport Service Implementors' Group. For this group, the aim of the document will be well understood - it is defining a service enhancement similar to the one that is already defined for X25 and the ones they are defining for their local campus networks. The aim is to provide a common transport service for all these systems. They will be unfamiliar with the detailed nature of the TCP itself, but this is not particularly important. The major interest of the document lies in the fact that the system being enhanced is not an ordinary local network, but an entire family of networks, and the resultant enhancement will make possible direct authorised access between UK and US hosts. I would also like to point out the issue of separating Yellow Book enhancements from ordinary uses of a network service. This issue is not addressed by the X25 enhancement specification. Much of the US Internetwork Group is likewise unfamiliar with the concepts and details of the Yellow Book Transport Service. A summary of these concepts will be made available in a later IEN. For them, the document will be of interest in that it shows how to coordinate two very different approaches to internetworking. The Catenet, based on TCP, can be described as a strongly connected internetwork system, with common transport protocols and a common address space. The UK Transport Service takes an approach based on providing a common service interface, which leads to a weakly connected system with common service protocols and no common address space. Within this approach, the entire Internet system appears as a single component Bennett 11 INDRA 965 Yellow Book above TCP network, as delimited by the TCP and its address space. 6. References [1] - PSS User Forum Study Group Three: "A Network Independent Transport Service" SG3/CP(80)2. February 1980. [2] - Information Sciences Institute: "Transmission Control Protocol" IEN 129.January 1980. Bennett 12 INDRA 965